Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis

A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that this organization produces. Specifically, products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem solving routines and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility and even the path of industry evolution. We explore this relationship in the software industry. Our research takes advantage of a natural experiment, in that we observe products that fulfill the same function being developed by very different organizational forms. At one extreme are commercial software firms, in which the organizational participants are tightly-coupled, with respect to their goals, structure and behavior. At the other, are open source software communities, in which the participants are much more loosely-coupled by comparison. The mirroring hypothesis predicts that these different organizational forms will produce products with distinctly different architectures. Specifically, loosely-coupled organizations will develop more modular designs than tightly-coupled organizations. We test this hypothesis, using a sample of matched-pair products. We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product's components. The magnitude of the differences is substantial - up to a factor of eight, in terms of the potential for a design change in one component to propagate to others. Our results have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.Organizational Design, Product Design, Architecture, Modularity, Open-Source Software.

Hidden Structure: Using Network Methods to Map Product Architecture

In this paper, we describe an operational methodology for characterizing the architecture of complex technical systems and demonstrate its application to a large sample of software releases. Our methodology is based upon directed network graphs, which allows us to identify all of the direct and indirect linkages between the components in a system. We use this approach to define three fundamental architectural patterns, which we label Core—periphery, multi-core, and hierarchical. Applying our methodology to a sample of 1,286 software releases from 17 applications, we find that the majority of releases possess a "core-periphery" structure. This architecture is characterized by a single dominant cyclic group of components (the "Core") that is large relative to the system as a whole as well as to other cyclic groups in the system. We show that the size of the Core varies widely, even for systems that perform the same function. These differences appear to be associated with different models of development—open, distributed organizations develop systems with smaller Cores, while closed, co-located organizations develop systems with larger Cores. Our findings establish some "stylized facts" about the fine-grained structure of large, real-world technical systems, serving as a point of departure for future empirical work

A Methodology for Operationalizing Enterprise Architecture and Evaluating Enterprise IT Flexibility

We propose a network-based methodology for analyzing a firm’s enterprise architecture. Our methodology uses “Design Structure Matrices” (DSMs) to capture the coupling between components in the architecture, including both business and technology-related elements. It addresses the limitations of prior work, in that it i) is based upon the actual architecture “in-use” as opposed to planned or “idealized” versions; ii) identifies discrete layers in a firm’s architecture associated with different technologies (e.g., applications, servers and databases); iii) reveals the main “flow of control” within an architecture (i.e., the set of inter-connected components); and iv) generates measures of architecture that can be used to predict performance. We demonstrate the application of our methodology using a novel dataset developed with the division of a large pharmaceutical firm. The dataset consists of all components in the enterprise architecture, the observed dependencies between them, and estimated costs of change for software applications within this architecture. We show that measures of the architecture derived from a DSM predict the cost of change for software applications. In particular, applications that are tightly coupled to other components in the architecture cost more to change. The analysis also shows that the measure of coupling that best predicts the cost of change is one that captures all direct and indirect connections between components (i.e., it captures the potential for changes to propagate via all possible paths between components). Our work represents an important step in making the concept of enterprise architecture more operational, thereby improving a firm’s ability to understand and improve its architecture over time

Visualizing and Measuring Enterprise Application Architecture: An Exploratory Telecom Case

We test a method for visualizing and measuring enterprise application architectures. The method was designed and previously used to reveal the hidden internal architectural structure of software applications. The focus of this paper is to test if it can also uncover new facts about the applications and their relationships in an enterprise architecture, i.e., if the method can reveal the hidden external structure between software applications. Our test uses data from a large international telecom company. In total, we analyzed 103 applications and 243 dependencies. Results show that the enterprise application structure can be classified as a core-periphery architecture with a propagation cost of 25%, core size of 34%, and architecture flow through of 64%. These findings suggest that the method could be effective in uncovering the hidden structure of an enterprise application architecture

Visualizing and Measuring Enterprise Architecture: An Exploratory BioPharma Case

We test a method that was designed and used previously to reveal the hidden internal architectural structure of software systems. The focus of this paper is to test if it can also uncover new facts about the components and their relationships in an enterprise architecture, i.e., if the method can reveal the hidden external structure between architectural components. Our test uses data from a biopharmaceutical company. In total, we analyzed 407 components and 1,157 dependencies. Results show that the enterprise structure can be classified as a core-periphery architecture with a propagation cost of 23%, core size of 32%, and architecture flow through of 67%. We also found that business components can be classified as control elements, infrastructure components as shared, and software applications as belonging to the core. These findings suggest that the method could be effective in uncovering the hidden structure of an enterprise architecture

Multivariate Unsupervised Machine Learning for Anomaly Detection in Enterprise Applications

Existing application performance management (APM) solutions lack robust anomaly detection capabilities and root cause analysis techniques, that do not require manual efforts and domain knowledge. In this paper, we develop a density-based unsupervised machine learning model to detect anomalies within an enterprise application, based upon data from multiple APM systems. The research was conducted in collaboration with a European automotive company, using two months of live application data. We show that our model detects abnormal system behavior more reliably than a commonly used outlier detection technique and provides information for detecting root causes

Designing an Agile Software Portfolio Architecture: The Impact of Coupling on Performance

The modern industrial corporation encompasses a myriad of different software applications, each of which must work in concert to deliver functionality to end-users. However, the increasingly complex and dynamic nature of competition in today’s product-markets dictates that this software portfolio be continually evolved and adapted, in order to meet new business challenges. This ability – to rapidly update, improve, remove, replace, and reimagine the software applications that underpin a firm’s competitive position – is at the heart of what has been called IT agility. Unfortunately, little work has examined the antecedents of IT agility, with respect to the choices a firm makes when designing its “Software Portfolio Architecture.” We address this gap in the literature by exploring the relationship between software portfolio architecture and IT agility at the level of the individual applications in the architecture. In particular, we draw from modular systems theory to develop a series of hypotheses about how different types of coupling impact the ability to update, remove or replace the software applications in a firm’s portfolio. We test our hypotheses using longitudinal data from a large financial services firm, comprising over 1,000 applications and over 3,000 dependencies between them. Our methods allow us to disentangle the effects of different types and levels of coupling. Our analysis reveals that applications with higher levels of coupling cost more to update, are harder to remove, and are harder to replace, than those with lower coupling. The measures of coupling that best explain differences in IT agility include all indirect dependencies between software applications (i.e., they include coupling and dependency relationships that are not easily visible to the system architect). Our results reveal the critical importance of software portfolio design decisions, in developing a portfolio of applications that can evolve and adapt over time

Exploring the Relationship between Architecture Coupling and Software Vulnerabilities: A Google Chrome Case

Employing software metrics, such as size and complexity, for predicting defects has been given a lot of attention over the years and proven very useful. However, the few studies looking at software architecture and vulnerabilities are limited in scope and findings. We explore the relationship between software vulnerabilities and component metrics (like code churn and cyclomatic complexity), as well as architecture coupling metrics (direct, indirect, and cyclic coupling). Our case is based on the Google Chromium project, an open source project that has not been studied for this topic yet. Our findings show a strong relationship between vulnerabilities and both component level metrics and architecture coupling metrics. Unfortunately, the effects of different types of coupling are somewhat hard to distinguish

Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis

A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that the organization produces. Specifically, products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem solving routines, and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility, and even the path of industry evolution. We explore this relationship in the software industry. Our research takes advantage of a natural experiment, in that we observe products that fulfill the same function being developed by very different organizational forms. At one extreme are commercial software firms, in which the organizational participants are tightly coupled, with respect to their goals, structure, and behavior. At the other, are open-source software communities, in which the participants are much more loosely coupled by comparison. The mirroring hypothesis predicts that these different organizational forms will produce products with distinctly different architectures. Specifically, loosely coupled organizations will develop more modular designs than tightly coupled organizations. We test this hypothesis, using a sample of matched-pair products. We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely coupled organization is significantly more modular than the product from the tightly coupled organization. We measure modularity by capturing the level of coupling between a product's components. The magnitude of the differences is substantial—up to a factor of six, in terms of the potential for a design change in one component to propagate to others. Our results have significant managerial implications, highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop